Subject: SNA over async over X.25

From: "Jim Martin ((919) 254-4471)" <[email-masked]>
Date: Thu, 21 Oct 93 09:52:25 EDT

Greetings:  I would like to start a discussion on how to expand the
scope of SNA-A to include connectivity across public data networks.
The key requirements are to minimize packet charges and to have the
carrier perform the async line concentration rather than having
a rack of async ports/modems on the customer premise.

Once approach is to get the carriers to support X.25 over async where
the async protocol is LAPB over async as defined by ISO 3309.  This
would require a full X.25 stack on the remote node.

Does anyone know of a switch which supports this?

My understanding is that dialup X.32 services are too expensive (especially
in some European countries) to make this be the ideal solution.

Another solution is to dial into a carrier's X.3 pad.  One approach is
to have the PAD do some type of a link switch on the data stream.
For example, the PAD could do a data link switch from SNA-A to
QLLC (as some switches can switch SDLC to QLLC today).  This would
allow a remote SNA node to connect into an existing SNA X.25 attached
node.   Note that this is one way that NT's DPN-100 can be used today.
Another alternative is to get the PAD to switch the link into a
frame relay format.  This would allow a remote SNA node to connect
with existing SNA frame relay attached nodes.

These are worth pursuing.  The problem is it requires support from
a carrier.  Perhaps if we work together as a consortium we might
be able to generate enough interest ....

A second approach to using X.3 pads is to have a DLC operate over
a switched virtual circuit between the X.3 pad and a X.25 attached
SNA node.  The analog would be the way SNA operates over X.25 today
using either QLLC or ELLC DLC protocols over switched or permanent
virtual circuits.  Since the path from the remote SNA node into
the X.3 node is unreliable, the DLC end to end protocol would have
to provide error detection and recovery.  The advantage of this
approach is that is adheres to CCITT standards and should be usable
over any carrier's network.

From a product point of view, using 802.2 as the DLC would
be the easiest (taking advantage of standard MAC interfaces such
as NDIS or ODI).  However this would  not be the most
efficient protocol.

Any comments are appreciated.
Regards,
Jim Martin
IBM Corporation

---

From: [email-masked]
Date: Fri, 22 Oct 93 10:34:01 EDT

Dear Jim,
   
 > with existing SNA frame relay attached nodes.
   At Netrix, we are currently have SDLC to QLLC conversion.  We intend
   implement SDLC over async to be handled from the remote Async
   device and our PAD (similarly to DPN-100).
   
 > be able to generate enough interest ....
   We can use the similar approach to support SNA-A under Data Link
   Switching.
   
 > over any carrier's network.
   Sorry, I am a bit confused here.  The DLC you suggest above, is it
   between the X.3 PAD and the X.25 attached SNA node or between the
   remote Async device and the SNA X.25 host?

Cheers,
==============================================================
Hung Bui                           Internet: [email-masked]
Netrix Corporation                    Phone: +1 703 793 1016
13595 Dulles Technology Drive           Fax: +1 703 713 3805
Herndon Va 22071
==============================================================

---

From: [email-masked]
Date: Fri, 22 Oct 93 17:06:44 EDT

Dear Jim,

   

Cheers,